The committers listed above are authorized under a signed CLA.

• ✅ login: cijothomas / name: Cijo Thomas (23fd53d, a46b881, e016808, b491c2d)
• ✅ login: MathieuTricoire / name: Mathieu Tricoire (aadc48f, 2809ede, bd0af70, 0809e5b, 2150812, 31f38a7, 156bb7a, 19b5c90, 710b2b2)
• ✅ login: lalitb / name: Lalit Kumar Bhasin (36fbc57, 509e48c)

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.3%. Comparing base (409713d) to head (0809e5b).
Report is 1 commits behind head on main.

@@          Coverage Diff          @@
##            main   #2898   +/-   ##
=====================================
  Coverage   81.3%   81.3%           
=====================================
  Files        126     126           
  Lines      24294   24294           
=====================================
  Hits       19774   19774           
  Misses      4520    4520           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@MathieuTricoire Re-exporting the whole tonic crate works, but it exposes all of tonic’s API as part of our public API. If we only need a few types (like MetadataMap), we could selectively re-export just those (e.g., pub use tonic::metadata::MetadataMap;). If more types are needed in the future, we can always add them as needed. Or do you see a reason to expose the whole crate up front?

@lalitb Thanks for the answer! That makes sense, and I'm totally good with cherry-picking. I actually thought about that, but I didn't want to overthink it right away if not necessary.

Going cherry-picking route, I see two options:

Flat re-export:

#[cfg(feature = "grpc-tonic")]
pub mod tonic_types {
    #[doc(no_inline)]
    pub use tonic::metadata::MetadataMap;
    #[doc(no_inline)]
    #[cfg(feature = "tls")]
    pub use tonic::transport::{Certificate, ClientTlsConfig, Identity};
}

Grouped by module:

#[cfg(feature = "grpc-tonic")]
pub mod tonic_types {
    pub mod metadata {
        #[doc(no_inline)]
        pub use tonic::metadata::MetadataMap;
    }

    #[cfg(feature = "tls")]
    pub mod transport {
        #[doc(no_inline)]
        pub use tonic::transport::{Certificate, ClientTlsConfig, Identity};
    }
}

I kind of like the module-based one, feels cleaner and easier to extend later to me, but maybe over-engineered? Happy to go with whichever makes more sense for you.

Also wondering what you think about the naming, would tonic_types work? Or maybe tonic_compat, tonic_export, or something else?

Also are you ok with the current re-export scope?

Let me know what direction you'd prefer and I'll adjust the PR 👍

I pushed the grouped by module proposal, let me know your thoughts.

thanks @MathieuTricoire - I agree - the module-based structure feels cleaner and more future-proof, especially if we add more exports later. So let's go with that.

CI has been fixed after the merge of #2945 and the PR should be ready for merging.

I have checked the Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes requirement, but do you think a CHANGELOG update is needed?

Hi @cijothomas, I've added the changelog entry, let me know if that works for you 👍